(1) Field of the Invention
The present invention relates to a broadcast receiving terminal, in particular, to a setup for facilitating viewing video, audio, and data such as a program by receiving a broadcast wave with which contents made up of video, audio, and data such as a program which are mutually synchronized are multiplexed, as well as a setup for overcoming the case where a contention of a resource such as a tuner occurs between the contents.
(2) Description of the Related Art
Various contents are included in a broadcast wave sent from a broadcast station. Aside from video and audio used in a normal TV show, there are cases where data is included in the contents. There are several methods for sending the data, which can be roughly divided into a method of sending the data chronologically and a method of repeatedly sending the data per set interval. In the former method of sending the data chronologically, for example, data that continues over the course of time is sent in sequential order. This method is suitable for sending large amounts of data over a long period of time, but there is a drawback in that data that could not be received due to timing of the send cannot be received again. On the other hand, in the later method of repeatedly sending the data at a set interval, the same data is repeatedly sent any number of times during a fixed period. This method has an advantage in that during the period when the same data is being sent, any one of the repeatedly-sent pieces of data can be received, and thus the timing of receiving is not limited. Data broadcast, represented by BML, and file sending through DSMCC data carousel are the examples of this method. It is unknown, particularly in broadcast, when a recipient will select a channel and commence reception. In the method of sending the data chronologically, when the start of reception falls behind the timing of the sending and acquisition of the data fails, the data cannot be re-acquired. Therefore, when sending data such as an application program along with video and audio in the broadcast wave, the method of repeatedly sending the data per set interval is favorable.
At present, specifications for receiving a broadcast wave that includes video, audio, and an application program and executing the application program in synchronization with video and audio, as in the above method, have been developed and are in operation. It is possible to receive the sent application program, load the application program into a broadcast receiving terminal (hereinafter to be simply referred to as “terminal” or “terminal apparatus”), and implement various extra functions by executing the application program, rather than simply viewing the video and audio. This method for sending the application program and importing the application program into the terminal is also called “downloading”. For example, a specification called Digital Video Broadcasting-Multimedia Home Platform (DVB-MHP) ETSIES201812 v1.1.1 (2003-12) has been developed in Europe, and operations according to this specification have already commenced. In addition, Open Cable Application Platform (OCAP), which provides the same specification in the cable broadcast environment in the United States, is being developed in the United States, and actual operations are set to commence. In these specifications, the application program is written in the Java language. Various Application Programming Interfaces (APIs) for tuning, graphics display, and the like are provided in the terminal, and the Java application program can control those functions by calling the APIs.
In addition, in North America, the OCAP-DVROC-SP-OCAP-DVR-I01-040524 specification, which is aimed at adding a function for recording and reproducing the contents in the OCAP specification, is being developed. With this specification, the video, audio, and the Java application program synchronized therewith are executed, which are sent as a cable television broadcast, are recorded as contents, and furthermore, are reproduced in the same manner as when the recorded contents are directly reproduced from the broadcast wave. The application program is reproduced in synchronization with the video and audio, in the same manner as direct reproduction from the broadcast wave.
Moreover, with OCAP-DVR, trick play of the contents is realized by recording broadcast contents to a high-speed random-accessible storage medium, such as a hard disk, a semiconductor memory, and the like. Here, the trick play refers to functions for reproducing the contents at an arbitrary speed, from an arbitrary position, and so on, such as fast-forward, rewind, slow-motion, pause, skip, and the like. With OCAP-DVR, the application program imported into the terminal from the broadcast wave can control the recording and trick play of the contents. In other words, APIs for recording and trick play are provided in the terminal, and the Java application program controls each function by calling those APIs.
Normally, in order that the application program is executed in synchronization with the video and audio, control information for the synchronization is already multiplexed in the broadcast wave. The application program is sequentially executed according to the synchronization control information and is terminated. Thus, it is possible to execute the application program by switching the program to an appropriate one in accordance with a specific scene of video and audio.
The OCAP and OCAP-DVR standards provide for the case where a contention between resources such as tuners and AV encoders occurs between the application programs, and defines a framework of invoking a handler previously registered by a privileged application program or a framework that is based on priorities held by the application programs, aiming to overcome such case.